🎯 Code Coverage (details)
• Patch Coverage: 54.15%
• Overall Coverage: 38.61% (+0.36%)

The diskFull disruption creates a ballast file on the host filesystem via the injector pod. The injector pod mounts the host root at /mnt/host, but that mount has ReadOnly: true — which was correct for all existing injectors (network, CPU, etc.) that only read the host. diskFull must write to the host, so it gets read-only file system ENOSPC before even starting.

Root cause

services/chaospod.go:573 — the host VolumeMount unconditionally sets ReadOnly: true:

     {
         Name:      "host",
         MountPath: "/mnt/host",
         ReadOnly:  true,   // ← must be false for diskFull
     },

Fix

1. Add a hostWritable bool parameter to generateChaosPodSpec

File: services/chaospod.go:466

Change signature:

     func (m *chaosPodService) generateChaosPodSpec(..., hostWritable bool) corev1.PodSpec {

Inside the function, use the parameter:

     {
         Name:      "host",
         MountPath: "/mnt/host",
         ReadOnly:  !hostWritable,
     },

2. Pass kind == DisruptionKindDiskFull from the call site

File: services/chaospod.go:332

     Spec: m.generateChaosPodSpec(
         targetNodeName,
         terminationGracePeriod,
         activeDeadlineSeconds,
         args,
         hostPathDirectory,
         hostPathFile,
         kind == chaostypes.DisruptionKindDiskFull,  // hostWritable
     ),

 **Critical files**

 - `services/chaospod.go` — only file to modify

Many thanks for the deep investigation. I will fix that ASAP. I still have concerns about allowing write to a complete FS for writing a ballast in a dedicated directory. It will allow someone with access to the pod to alter the disrupted pod/node for purposes other than the expected disruption.

I will propose a security gate.

Could you also create an example file to test locally the disruption:

example/disk_full.yaml

# Unless explicitly stated otherwise all files in this repository are licensed
# under the Apache License Version 2.0.
# This product includes software developed at Datadog (https://www.datadoghq.com/).
# Copyright 2026 Datadog, Inc.

apiVersion: chaos.datadoghq.com/v1beta1
kind: Disruption
metadata:
  name: disk-full
  namespace: chaos-demo
spec:
  level: pod
  selector:
    service: demo-curl
  count: 1
  duration: 10m
  diskFull:
    path: "/mnt/data"
    capacity: "95%"

Could you also update the examples/complete.yaml please

Could you also update the docs/README.md to add a link to the docs/disk_full.md disruption please

Full review comments:

• [P1] Remove the pod-path HostPath mount — /Users/aymeric.daurelle/go/src/github.com/DataDog/chaos-controller/services/chaospod.go:689-695
  When diskFull.path targets a normal pod volume such as an emptyDir/PVC mounted at /data, this value is a container mount path, not a node path. Adding it as a HostPath with type Directory makes kubelet require /data to exist on the node, so the chaos pod can fail before the injector resolves the real /var/lib/kubelet/pods/... backing path.

• [P2] Fix the rejected 100% example — /Users/aymeric.daurelle/go/src/github.com/DataDog/chaos-controller/docs/disk_full.md:81-81
  This documented manifest is rejected by safetyNetDiskFullMinFreeSpace, because capacity >= 100 returns an error before unsafeMode.allowDiskFullNoFloor is considered. Users following the example cannot create the disruption unless the webhook behavior or the example is changed.

Full review comments:

• [P1] Remove the pod-path HostPath mount — /Users/aymeric.daurelle/go/src/github.com/DataDog/chaos-controller/services/chaospod.go:689-695
  When diskFull.path targets a normal pod volume such as an emptyDir/PVC mounted at /data, this value is a container mount path, not a node path. Adding it as a HostPath with type Directory makes kubelet require /data to exist on the node, so the chaos pod can fail before the injector resolves the real /var/lib/kubelet/pods/... backing path.
• [P2] Fix the rejected 100% example — /Users/aymeric.daurelle/go/src/github.com/DataDog/chaos-controller/docs/disk_full.md:81-81
  This documented manifest is rejected by safetyNetDiskFullMinFreeSpace, because capacity >= 100 returns an error before unsafeMode.allowDiskFullNoFloor is considered. Users following the example cannot create the disruption unless the webhook behavior or the example is changed.

@aymericDD, it would be interesting to have configuration validation tests. Because most of the configuration files acting as examples are not validated in CI. That would help to spot such discrepancies, especially when we introduce new feature or schema breaking changes.